Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

SmartObject table example

To illustrate the relationships among these tables, we use an example from Chapter 3, "Advanced User Interface Design in Progress Dynamics," the Order Entry Maintenance window oemaintwin. Figure 8–2 shows a rough sketch of the object type, SmartObject, and object instance records that make up Page 0 of this window.

Figure 8–2: Order entry maintenance window records

It is too complicated to show all of the connections for every object. Those that are here show the relationships from the window itself, which you can then extend to apply to all the other objects. To simplify the diagram a bit, we have left off the table prefixes.

To follow the diagram, start with the container window itself, the SmartObject oemaintwin. This is the master record for the window. When the framework must run this window, because of a request from the Dynamic Launcher, from the AppBuilder, or from an action defined for a menu or toolbar item, it locates this record to determine what to do.

There are five principal connections between the SmartObject record and other records that help to define it:

First, there is a pointer to its object type record, the type DynObjc, or independent window. This record in turn is connected to a number of attribute value records that define default attribute values for all windows of this type, as well as other information. For more information on attribute values and other relationships, see the "Attribute tables" section.
Next, there is the product_module record, which identifies this window as being in the OE product module.
Next, there is a pointer to the Layout record for the Relative layout, the one used for all windows built in the framework. This holds, among other information, the name of the procedure that does the layout at run time, rylayoutsp.p.
Finally, there are pointers to two other SmartObject records. The custom_smartobject_obj pointer connects to the SmartObject record that defines the custom super procedure for the window, the procedure oemaintwinsuper.p. And the physical_smartobject_obj pointer connects to the SmartObject record that defines the generic object for dynamic windows, the procedure rydyncontw.w, which reads all these records and creates the window at run time.

Those are the records from the object_type, SmartObject, and object_instance tables that together describe the window itself as an object. Just as some of its attributes come through the object type, the window SmartObject record also points to attribute value records for attributes defined at the master level of the window. For more information on attributes defined at the master level, see the "Attribute values defined at the object instance level" section.

Of course, the window is just a container for other objects. These are represented as object_instance records because they are instances of other SmartObjects as used in this window. In this case, there are two object_instance records for the two objects on Page 0 of the window (as well as others for the other pages that we have left off here for simplicity), the FolderPageTopToolbar instance and the folder object instance of afspfoldw.w.

Each of these object_instances in turn points to its own SmartObject record for the master object. Again, some of each object’s attributes are defined in the master, some are defined for the instance, and some are inherited from each object’s class (object type).